A typical data access environment has a multi-tier architecture. For description purposes, it can be separated into three distinct tiers:                Web server        Applications        DataThe tiers are based on business function, and are typically separated by firewalls. Client software, such as a browser or a report-authoring tool, sits above the tiers.        
The web server contains a firewall and one or more gateways. All web communication is performed through a gateway. A gateway is responsible for passing on requests to the application server, in tier 2, for execution.
The applications tier contains one or more application servers. The application server runs requests, such as reports and queries that are forwarded by a gateway running on the web server. Typically, one of the components of the applications tier is a query engine, which is data access middleware that provides universal data access to a variety of heterogeneous database systems. The query engine formulates queries (typically SQL) and passes them on to the data tier, through a native database API (such as ODBC) for execution.
The data tier contains database management systems (DBMS), which manage raw data stored in a database. Examples of such systems include Oracle, DB2, and Microsoft SQL Server.
Although a multi-tier architecture can be configured in several different ways, a typical configuration places each tier on a separate computer (server). A database server is typically a “high end” server, and thus can process queries at a relatively fast speed. An application server cannot generally process queries as quickly as a database server.
In order to solve many business questions, a query engine may generate SQL queries that utilize the SQL/OLAP technology introduced in the SQL:1999 standard. However, many database systems do not support this technology. Thus, the SQL queries would have to be performed by the query engine on the application server that is generally slower than the database server. It is desirable to have as much processing performed on the database server as possible.
There is a need to prevent or reduce the amount of local (application server) processing required to process a query. In the past, the application would be responsible for generating SQL that contained a standard GROUP BY query. Quite often, generating this type of SQL is more difficult since it is more complex.
One way of overcoming this problem is for the query engine to generate a GROUP BY query to compute aggregates at the lowest level of granularity, and then compute the remaining aggregates based on these values. This approach reduces the amount of processing time required on the application server.